Retail store managers continually monitor individual point of sale (POS) terminal and POS terminal operator or clerk performance for areas of improvement and error or problem detection and identification. Poor performance by either terminal or clerk impacts the overall profitability of the store. One method of monitoring is to record timing information about the clerk and POS terminal during job performance. Several approaches are available to record timing information, such as 1) software or hardware based automated time recording or 2) direct or videotaped observation and human factors engineering and analysis.
Under the first approach identified above, automated time recording, the POS terminal software records timing information about the clerk and events occurring at the terminal. However, typical retail POS terminal software retains only a small set of the overall timing information in summary form as described in copending application entitled “Method and Apparatus for Determining the Retail Performance Metric of Entry Identification Time.” Any and all recorded occurrences at the POS terminal are categorized and accumulated into one of six time type categories, such as ring time, tender time, secure time, non-sales time, idle time, and no time. Categories may be added, subtracted or modified as necessary or as dictated by the configuration of the store. As a result of this type of time measurement, only a portion of the time spent in each of the time type categories is under the direct control of the POS terminal operator. For example, the operator controls how quickly items are scanned and tenders are inputted but has no control over other actions that contribute to these time measurements. Such additional factors contributing to the time measurements include the bar code quality in the product mix presented to the operator, the types of error warning levels configured in the store, and the various tender validation requirements active at the store. For example, a store may have a policy requiring that all checks be presented accompanied by at least two pieces of identification, or the bar code on certain products may not be of the same quality as other products and may require multiple scan attempts or keyed input for entry of the product. The additional time required is unable to be separated from the category times and viewed or analyzed independently or on a per entry basis. Thus, there is a need in the art to enable tracking of individual occurrences within the defined categories.
Another problem identified in prior art systems is that the granularity of the timing information is very broad, i.e., typically the timing information is written to the transaction log (TLOG) as a single record with summarized totals for an entire transaction. Each transaction in the transaction log records the interaction of the operator and/or POS terminal with a customer and includes transaction entries recording events indicative of occurrences during the transaction. The transaction events include “scan” indicating a product bar code scan, “key” indicating a product identification using an input device, usually a keyboard, and “tender” indicating a customer providing payment. There are additional types of transaction events known in the art. Typically, a transaction entry in the transaction log includes a terminal identifier, an operator identifier, an event type, and an indication of the items purchased by the customer, if applicable. However, timing information, if recorded, is stored in the summarized time type category totals. For example, if the operator spends three periods of time in ring time and two periods of time in secure time during a transaction, the transaction log will only reflect the total for each of the periods of time spent by the operator in secure time and ring time, but not the individual amount of time spent in each of the secure time or ring time periods for each entry or event during a transaction. In other words, if the three periods of ring time include a ten second period, a twelve second period, and a fifteen minute period, the transaction log will indicate a ring time of fifteen minutes and twenty-two seconds, possibly indicating an operator with a high ring time. In fact, the fifteen minute period may be due to operator or system errors, but is less likely to be discovered using prior approaches. Thus, to provide more accurate indications of efficiencies, and conversely, inefficiencies, there is a need in the art to enable logging of individual time period occurrences within the defined categories and/or individual transactions.
As retailers become more concerned with increasing overall system performance, increasing profits and lowering costs, it is more important to separate the high-level time measurements or time summaries of the time type categories into the individual components making up the summaries. An important portion of this time occurs during the time period when the operator is commanding the POS terminal to do something such as add a product to a customer's purchase order, otherwise known as the “entry identification” time. As used in this specification, entry identification time is the time period during which the POS terminal waits for operator input and the operator inputs a particular entry into the POS terminal or tells the POS terminal to do something. The entry identification time is the time period over which the operator has the greatest amount of control and the one that most correctly measures their performance. Thus, there is a need in the art to track a performance metric, for example, a metric known as entry identification time.
As identified above, the second approach to solving these problems is to apply industrial or human factors engineering methods to obtain and analyze operator and POS terminal performance. These methods include time-and-motion analysis, video task analysis, and stop-watch measurements. Human factors engineering companies offer services to retailers, such as performing video data collection and task analysis on front-end check out operations. The data collected aids human factors engineers to quantify the productivity of the operator and POS terminal, identify bottlenecks, and make recommendations for POS terminal or check stand design, process changes, and technology to improve productivity. Because the human factors engineering methodology provides detailed, accurate, and quantifiable data, cost-benefit calculations can be made to demonstrate the financial impact of implementing a recommendation.
However, industrial engineering approaches and human factors engineering analysis techniques have a number of limitations. For instance, the techniques are labor intensive and costly for retailers. In order to obtain statistically valid results, a large data sample is required necessitating many hours of costly observation and analysis.
Due to the cost, typically only a small sample of data (ranging from approximately a few hours to one week's worth) is collected resulting in insufficient sample sizes which negatively affects statistical validity, interpretation of the data and quality of the results. Continuous data collection over months or years, desirable for longitudinal studies (e.g., long-term trend analysis) is cost prohibitive. The potential for human error is inherent in this type of data collection and analysis.
Thus, there exists a need in the art for a method to provide automatic, continuous, consistent, and detailed data storage of retail performance metrics. Any solution must capture timing information for each individual action of interest and should include a mechanism to associate the timing information with the transaction in which the action occurred and/or should be linked with the appropriate time type category.
A possible solution to recording RPM data includes adding extra fields into the transaction entry records currently existing in the TLOG in order to capture the RPM data. Disadvantageously, this approach does not allow for easy processing of the RPM data when analyzing the TLOG. Using this approach, an analyst would have to process many different types of records to get all of the RPM data of a particular RPM type or time type category.
Additionally, this approach does not easily provide for future RPM type or time type category definitions occurring within the context of actions not currently defined in the TLOG. In other words, the TLOG would need to be redesigned for the capture of additional RPM types or time type categories. There is a need in the art for a standard TLOG record format for recording RPM data in a consistent manner while providing the flexibility to add new RPM type and/or time type category definitions.